|
|
|
| FIELD NAME | VALUE | RAW DATA | | Data1 | 61D61E8 | E8 61 1D 06 | | Data2 | 422B | 2B 42 | | Data3 | 11D2 | D211 | | Data4 | A7 87 00 00 1C 1A D1 F8 | A7 87 00 00 1C 1A D1 F8 | | Table S26-1: Representations of GUID data |
|
|
|
|
|
|
Here you can see the effects of byte ordering on the way data is displayed. (You can read more about this in Tutorial 2, "Memory, Where It All Begins," found in Part III of this book.) |
|
|
|
|
|
|
|
|
Why am I going to all this trouble to show you these two different ways of looking at the data? Because you may find yourself dealing with both of these representations on occasion. Even though objects are usually referred to in programs by program ID, any time you need to look under the hood in a Visual Basic project file or in the system registry, you will see the CLSID in a format that looks something like this: |
|
|
|
|
|
|
|
|
{061D61E8-422B-11D2-A787-00001C1AD1F8} |
|
|
|
|
|
|
|
|
As you can see, the data in this format is very similar to the value displayed in the second column of Table S26-1. The only difference is that the Data4 array is divided into a group of 2 bytes and a group of 6 bytes. |
|
|
|
|
|
|
|
|
This string representation of a CLSID is used almost universally by applications and data files that display CLSID information in a format intended to be viewed by people. Where, then, might you run into the raw data? You'll see CLSIDs in the raw data format when you examine memory under a debugger, such as the Visual C++ debugger. |
|
|
|
|
|
|
|
|
Given that the string format is frequently used, you might wonder if there is a function to convert between a CLSID structure and a string representation of a CLSID. There is, and that will be the subject of Puzzle 27. |
|
|
|
|
|